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REMARKS 

L Introduction 

In response to the Office Action dated April 19, 2004, claims 1 and 27 have been amended 
Claims 1-40 remain in the application. Re^eraininauon and re-consideration of the application, as 
amended, is requested. 

II. Claim Amendments 

Applicants* attorney has made amendments to the claims as indicated above. These 
amendments were made solely for the purpose of clarifying the language of the claims, and were not 
required for patentability or to di$tingaish the claims over the prior art 

III. Prior Arc Rejections 

On page (1) of the Office Action, claims 1-40 were rejected under 35 U.S.C. §1 03(a) as being 
unpatentable over Richcon, U.S. Patent No. 6,650,902 (Richton) in view of Mayra*, U.S. Publication 
No. 2003/0105826 Al (Mayraz). 

Specifically, the independent claims were rejected as follows: 

As per claims 1, 15 and 27: 

Richton discloses a system providing location based service information to a wireless mobile 
unir comprising: 

storing a compact definition of a schema (simple commands) of an external database (fig. 3, 
#305, location based preferences)) wherein the external database comprises a user's profile 
information (the preferences users) (col. 3, lines 23-27); 

storing data source information (location based server, fig. 3, #302) that describes how to 
connect and communicate with the external database {location based preferences translates and 
cooperates with the location based service database to permit simple commands to be transmitted to) 
col 3, lines 3SM3); and 

storing positional informaiton (GIS or GSP) for the record in the external database as a 
geocoding index (coL 4» lines 15-27); 

providing access (to/from WSC, fig. 3, # 220) to the user's profile information using the 
stored compact definition, data source information, and positional information (Fig. 3, # 320, 
Internet, # 340, other sources, external information sources, coL 4, lines 52-65). 

Richton does not explicitly teach storing a structured query language (SQL) statement that, 
upon execution, extracts properties from the external database corresponding to the compact 
definition and storing a foreign key that identifies a record in me external database. However, Mayraz 
teaches the system stares user profiles corresponding to user's characteristics. Mayrafc teaches storing 
a structured query language (SQL) statement that, upon execution, extracts properties from the 
external database corresponding to the compact definition (determination of which user profiles 
match to the target profiles is implemented by SQL statement), fll°163) storing a foreign key (user 
table and user contact data table) that identifies a record in the external database fl[0l49-0l52). Thus, 
it would have been obvious to one of ordinary skill in the art at the time the invention was made to 
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combine the teachings of the cited lefeuences to implement the step of storing a structured query 
language (SQL) statement that, upon execution, extracts properties from the external database 
corresponding to the compact definition and storing a foreign key thai identifies a record in the 
external database because it enable verification of matching when place names are included in the 
target profiles faster and more accurate fl[0213). 

Applicants traverse the above rejection for one or more of the following reasons: 

(1) Neither Richton nor Mayraz teach, disclose or suggest a compact definition of a 
schema of an external database; 

(2) Neither Richton nor Mayiafc teach, disclose or suggest data source information that 
describes how to connect and communicate with an external database; 

(3) Neither Richton nor Mayraz teach, disclose or suggest storing positional information 
for a record as a geocoding index in local memory, wherein the record is in an external database; and 

(4) Neither Richton nor Mayraz teach, disclose or suggest storing a foreign key with 
positional information, in local memory, for an external database record. 

Independent claims l s 15, and 27 are generally directed to location enabling a user's profile 
information in an external database. As stated in the specification, user profiles may be stored in an 
external database that may not be completely accessible or that one may not want to transfer into 
local memory. However, access to such an external database is still useful. To provide such access, 
a compact definition of a schema for the external database is stored in local memory. In addition, 
data source information that describes how to connect and communicate with the external database 
is stored in local memory. An SQL statement is also stored in local memory, where the SQL 
statement (upon execution) extracts properties from the external database corresponding to the 
compact definition. To location enable the records in the external database, a foreign key that 
identifies a record in the external database is stored locally. Further, positional infor ma tion (in the 
form of a geocoding index) is stored in local memory for the record identified by the foreign key. 
Accordingly, based on the claims, the local memory contains a schema definition, data source 
information, an SQL statement, a foreign key, and positional information for each foreign key. 
Using each of the stored elements, the invention provides access to the externally stored user profile 
information. 

The cited references do not teach nor suggest these various elements of Applicants' 
independent claims. 
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The Office Action iclies on Richton to teach various claim elements. Firstly, the Office 
Action equates the compact definition of a schema to Richton's "simple commands", the external 
database to Richton's location based preference server, and the user's profile information to the 
preferences users in coL 3, lines 23-27. Applicants respectfully traverse such a suggestion. 

Applicants submit that Richton's simple commands are not even remotely similar to a 
schema or a compact definition of a schema, implicidy or explicidy. Recent case law varies on 
whether the specification or dictionary definition prevails when defining a claim term. However, 
Applicants submit that whether a dictionary definition or the specification is used, Richton still fails 
to teach the claimed schema- Paragraphs [0062]-[0064] of the present specification specifically 
define the claimed schema and compact definition: 

[0002] FIG. 5 illustrates the structure of a schema 134 for an external database 128-130 in 
accordance with one or more embodiments of the invention, As described above, the schema 
definition 134 rnflmrains information about external data sources 128-130. Each schema 134 
definition stored by the LBS application 110 provides a description for each object in the external 
database 128-130. In other words, there is a corresponding schema 134 for each object in the external 
database 128-130- For example, an address object m the external database 128-130 will have a 
corresponding schema definition 134. Further, for each ficld/atmbute in the object, a correaponding 
attribute definition 502 is scored with me schema 134, For example, the address object has multiple 
fields /attributes such as name, number, street name, city, state, and zip. For each field/ attribute, a 
schema attribute definition 502 is stored with the schema 134. 

[0003] The type of database 504 (Le., itemType : String; e.g., Address) in the schema 134 provides 
the type or a name for the object in the external database 128-130. Data source information 506 (Le., 
jdbcData Source : String) provides information regarding how to connect and communicate with the 
external database 128-130. Such information may fully define where the data is, including its database 
128-130, its row, and its column. For example, information regarding which carrier 126 is hosting a 
particular database 128-130 and how to communicate with the database 128-130 is stored. 
[0004] As described above, a list 508 of attributes is set forth in the schema 134. For each attribute, 
an attribute definition 502 provides the name of the attribute, the type of attribute and a constraint of 
the attribute- Thus, for each schema 134, a single list 508 maps to multiple attribute definitions 502. 

As set forth in the above language, the schema definition "main rains information about 
external data sources" and "provides a description for each object in the external database". Thus, a 
schema definition as set forth in the specification provides information about the claimed external 
database and a description of objects in the external database. 
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The dictionary (http: / /www.techwebxom/encyclopedia / defin<rcmi?term= schema) defines 
a schema as follows: 

Pronounced "skee-mah." The definition of an entire database It defines the structure and 
the type of contents that each data element within the structure can contain. Schemas ace often 
designed vAth visual modeling tools that automatically create the SQL code necessary to define the 
table structures. See subschema and XML schema. 

Under the dictionary definition, a schema defines a database including the structure and type 
of contents that each data element within the structure can contain. 

Thus, the dictionary is consistent with the specification in terms of the definition of the terra 
"schema". The Office Action provides that the compact definition of a schema is equivalent to 
"simple commands". However, as can be seen by the above definitions, "simple commands" do not 
provide a structure for the contents of a database, nor do "simple commands" provide information 
about external datasources. Instead, as set forth in Richton, "simple commands" are merely 
transmitted to a wireless mobile unit (see col 3, Hnes 39-42). Such "simple commands" are not even 
remotely similar, nor do they describe, teach, suggest, or allude to such structure or infortnation. In 
this regard, a command delivered to a wireless device does not provide any information about an 
external database. 

The Office Action is also confusing the temiinology used in the claims, using Richton's 
temiinology inconsistently, and applying Richton's terminology to the claims in a manner that is not 
possible. The Office Action provides that the schema is equivalent to the simple commands, the 
external database is equivalent to location based preferences server 305, and the claimed wet's 
profile information is equivalent to the preferences users described in coL 3, lines 23-27. The Office 
Action then provides that the claimed storage (in local memory) of data source information that 
describes how to connect and communicate with an external database is equivalent to the location 
based preferences server translating and cooperating with the location based service database "to 
permit simple commands to be transmitted to". As claimed, the data source information describes 
how to connect and communicate with an external database. The cited claim language leaves off the 
end of the sentence that clearly differentiates the cited portion from the claim limitations. 
Specifically, the location based preferences server translates and cooperates with the location based 
service data base to permit simple commands "to be transmitted to the wireless mobile unit 201" . 
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Thus, while the claim* provide for information regarding how to communicate with an external 
database, Richton merely describes how to send commands to a wireless mobile unit Such a 
wireless mobile unit is not equivalent or even remotely similar to the claimed external database. In 
fact, Richton's FIG. 2 and 3 dearly illustrate mar the wireless mobile unit and location based services 
database are different. Based on the language in the Office Action, if the external database is 
equivalent to the location based service database (or the location based preference server), it cannot 
also be equivalent to the wireless mobile unit. 

The claims further provide for storing, in the local memory, positional information, for the 
record in the external database. In rejecting this element, the Office Action merely recited coi 4, 
lines 15-27. However, coL 4, lines 15-27 merely indicates that the location based service database 
(that includes the instruction information, position information, remote location info, etc. (see col. 3, 
lines 11-22)) contains GIS processing software. The earlier portion of the Office Action provides 
mat the external database is equivalent to the location based preferences server and location based 
service database. Now, the Office Action is stating that the positional information is stored in the 
location based service database (Le., the same database). However, the claims clearly provide that 
the positional information (that is for a record in the external database) is stored in local memory as 
a geocoding index. For example, prior claim 16 (which has not been amended) clearly established 
that the positional information is stored in the LBS database for the record located in the external 
database. Thus, the claims provide for storing the positional information (for a record in an external 
database) in a local database or memory. Richton merely illustrates that positional information can 
be stored in the same database as the other described information. Such a similar database does not 
remotely suggest or allude to the storage of positional information in either local memory, or an LBS 
database that is distinguishable from the external database as set forth in the claims. 

The claims further provide for providing access to the user's profile information (that is 
Stored in the external database) using (1) the stored compact definition; (2) the data source 
information; (3) die SQL statement; (4) the foreign key; and (5) the positional information. The 
rejection breaks up the single claim element and relies on Richton to teach providing access based 
on items (1), (2), and (5), while ignoring the other elements. In fact, the Office Action never relies 
on any art nor addresses the specifically claimed limitations of providing access using the foreign key 
and SQL statement. Applicants note that it is improper to break up the cl a im element as done in the 
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Office Action. In this regard, die claim must be examined as a whole. Under MPEP §2142, the 
claimed invention must be examined as a whole and whether the **whole M claimed invention would 
have been obvious at the time of invention. The claims recite a method step for providing access 
based on various specific attributes together. By breaking up the elements that are relied upon when 
applying the prior art, the Office Action is not examining the claims or individual elements "as a 
whole" as required under MPEP §2142. 

Additionally, specifically claimed limitations (e.g., providing access based on the SQL 
statement and foreign key) cannot merely be ignored For example, under MPEP §2142 and 
2143.03 <s To establish prima facie obviousness of a claimed invention, all the claim limitations must be 
taught or sugge$tcd by the prior art. In re Rayka> 490 R2d 981, 180 USPQ 580 (CCPA 1974). "AH 
words in a claim must be considered in judging the patentability of that claim against the prior art" 
In n Wilson, 424 R2d 1382, 1385, 165 USPQ 494, 496 (CCPA 1970).'* Accordingly, the Office 
Action's failure to address the providing access method step that uses the SQL statement and 
foreign key is contrary to accepted PTO practices. 

The claims also provide for storing an SQL statement that, upon execution, extracts 

properties fiom an external database corresponding to the compact definition. In other words, the 

SQL statement itself is stored in the local memory (in claim 1) chat if and when it is executed will 

extract properties from the external database. The Office Action admits that Richton fails to teach 

this claim element. Instead, the Office Action relies on Maytaa paragraph 0163 which provides: 

[0163] At step S20, control 124 analyses the database contents to determine those users which have 
user profile data that complies with the target profile attached to the message. Determination of 
which user profiles match the target profile is implemented by a conventional database querying 
procedure employing Structural Query Language (SQL), since all the criteria described above can be 
determined on a yes/no basis. Even in the case of location, the above described form of the place 
name hierarchy enables verification of matching when place names arc included in the target profile, 
A further possibility is for the target profile to specify that recipients of the message should be located 
within a given distance from the location of the message sender, or even from a particular other place. 
In this situation, in order for the standard database query procedure to be implemented, the following 
procedure is first carried out by control 124, Control 124 determines the square distance of each user 
from the message sender by analysing the UMC data held fox each user. Preferably however, the 
number of users this needs to be performed with is significantly reduced by identifying the particular 
am within the area hierarchy structure 168 that is the smallest area in which the distance criteria can 
be met. The square distance calculation need then only be performed for those users who contain that 
area within their user profile. Another possibility when target profile contains a maximum distance is 
to treat this as only being so specific as to allow server 2 to define all users within whichever is the 
smallest hierarchical level of the area hierarchy structure which allows all distances under the distance 
criteria to be included, even if some in feet would be found to be beyond it with an individual 
calculation of the square distance. Whether the location details should be matched before other 
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details, or indeed the choice of which order any of the other profile details should be compared in is 
determined according io the requirements of the particular system under consideration. 

As can be seen, Mayiaz merely provides for determining which user profiles match a target 
profile using SQL. However, an SQL statement is not stored (for later use to extract properties 
from an external database), Additionally, the SQL statement merely compares a user profile to a 
target profile. There is no description, implicit or explicit, that Mayraz' SQL statement extracts 
properties from an external database. In facta Applicants submit that Mayraz fails to teach the 
claimed external database or the compact definition. Without teaching the claimed external database 
or compact definition of the database, Mayra2 cannot possibly teach extracting information from the 
external database corresponding to the compact definition. 

The claims specifically recite storing, in local memory, a foreign key that identifies a record 
in the external database. Thereafter, positional information for the record (identified by the foreign 
key) is also stored in local memory, as a geocoding index. Thus, as cl a i m ed, for each foreign key, 
positional information and the foreign key are stored in local memory (claim 1) or an LBS database 
(claim 15) that is separately identified from the external database. In rejecting the foreign key daim 
element, the Office Action relics on paragraphs 0149-0152. However, these paragraphs merely 
describe a user table that is linked to a user contact table (and not separate databases) via the user 
ID. Accordingly, instead of storing a foreign key with positional information (as clai m ed), Mayra* 
merely describes a prior art relational database system where tables may be linked via a common 
field (Le,, the user ID). Such a teaching in Mayraz does not and cannot teach, implicidy or explicitly, 
the specifically claimed foreign key and positional information storage for the record identified by 
the foreign key. Again, Mayraz fails to describe the external database, foreign key, and positional 
information as set forth in the claims. Further, these claims cannot be dissected and examined 
independently from each other. Instead, the claim must be examined as a whole including die 
relationship between the claim elements. The Office Action fails to reject the claims in this maimer. 
Additionally, neither Richton, nor Mayraz, either alone or in combination, teach, disclose, or suggesr 
the invention as claimed 

Moreover, the various elements of Applicants* claimed invention together provide 
operational advantages over Richton and Mayraz. For example, neither Richton nor Mayraz 
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location enable an external database as claimed. In addition, Applicants 1 invention solves problems 
not recognized by Richton and Mayia^. 

Thus, Applicants submit that independent claims 1,15, and 27 axe allowable over Richton 



and Mayraz. Further, dependent claims 2-14, 16-26, and 28-40 are submitted to be allowable over 
Richton and Mayra2 in the same manner, because they are dependent on independent claims 1,15, 
and 27 \ respectively, and thus contain all the limitations of the independent claims. In addition, 
dependent claims 2-14, 16-26, and 28-40 recite additional novel elements not shown by Richton and 
Maytaa. 

IV. Conclusion 

In view of the above, it is submitted that this application is now in good order for allowance 
and such allowance is respectfully solicited- Should the Trgaminer believe tninor matters still remain that 
can be resolved in a telephone interview, die Examiner is urged to call Applicants' undersigned 



attorney. 



Respectfully submitted, 



GATES Sc COOPER LLP 



Attorneys for Applicants) 



Howard Hughes Center 
6701 Center Drive West, Suite 1050 
Los Angeles, California 90045 
(310) 641-8797 
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